Development Diary
ft-malloc
オリジナルを動かす・manとsubject読んで学習: 4日
作ってみる: 2日
subjectのalign理解してなくてやり直し: 2日
テスト: ?日
manとsubjectを最初に読み込むのはやっぱり大事
データ設計はAIと相談しながら結構詰めた方が良い
学習 -> とりあえず作成 -> ちゃんとデータ設計、やり直し -> テストの順番だった
反省
学習で一部使用を見落としていたので、やり直しが入った。
データ設計を何回かやり直した。
とりあえずAI と一緒に書いちゃったからだと思う。
次回以降 学習 -> データ設計 w/ AI -> テスト -> コードをAIと が良いと思う
あとディレクトリや命名は、こだわらなくてもいいと思う。
Makefile
絶対後で書き直すことになる。
テスト書いてみてる
o3と相談してtableにまとめる -> Cloud 3.7 Sonnet にテストコードに直させる。
munit Simpleで素晴らしい。
forkするのでデバッガーでの追跡がむずいな VSCode Debuggerで子プロセスをデバッグする。
please write every single tests on @test.md using @MUnit to @test.c .don't write at once, After writing one test, run it with Make run-test to check if it works properly. let's go step by step.here is the first example.
って言ったらいい感じに書き始めてくれた。
テストに失敗すると、テストを寛大にして対処しようとし始めたので、撃詰めしたら反省してくれた。
でもちょっとclaude 3.7 アホだな。別でO3にも相談してたけど、全然質が違う。 gemini 2.5 proは割とO3に近いかも。
AI Coding Agentとの付き合い方
Never make test Lenient. , if, even if if failed. Don't care about the result of the test. Just focus on materializing the test from the test list.
結局、テストの結果を見せちゃうと、どうしても気にしちゃうかもしれないから。 コンパイルが通るかだけ、確認させたほうがいいかも。
テストが不十分でレビュー落ちた。
まぁ、レビューの目的が達成されている
プロジェクトの各段階において、 他者の視点を入れることが大事。
プロジェクトの進め方
やっぱり自分で使うものを作ろう(ドッグフーディングが重要)
haskell久しぶりに触ってみたら、環境構築の問題も消えてて最高!
HLSがこの上なく充実している
思考がそのまま出て来て、素直に自分の考えていることを書ける
やりたいことが一番素直な形で全くの制限なしにできる
他の言語でイライラするところが全くない
Haskell再入門
features/src/haskell at main · devcontainers-extra/features · GitHub
いやfeaturesが勝手にコケるコミットしやがる。。
と思ったけど、違った。すいません。
devcontainersのrebuild without cacheは冪等性が微妙かも？
docker側で消してからやり直したら、冪等性が出た。
devcontainerがclusterで動かない。
こんなノリのエラーが出る
"remoteUser": "root"にしないといけないが、納得いかない
code: .log
RUN eval $(sed -n "s/${REMOTE_USER}:^:*:\(^:*\):\(^:*\):^:*:\(^:*\).*/OLD_UID=\1;OLD_GID=\2;HOME_FOLDER=\3/p" /etc/passwd); eval $(sed -n "s/\(^:*\):^:*:${NEW_UID}:.*/EXISTING_USER=\1/p" /etc/passwd); eval $(sed -n "s/\(^:*\):^:*:${NEW_GID}:.*/EXISTING_GROUP=\1/p" /etc/group); if -z "$OLD_UID" ; then echo "Remote user not found in /etc/passwd ($REMOTE_USER)."; elif "$OLD_UID" = "$NEW_UID" -a "$OLD_GID" = "$NEW_GID" ; then echo "UIDs and GIDs are the same ($NEW_UID:$NEW_GID)."; elif "$OLD_UID" != "$NEW_UID" -a -n "$EXISTING_USER" ; then echo "User with UID exists ($EXISTING_USER=$NEW_UID)."; elif "$OLD_GID" != "$NEW_GID" -a -n "$EXISTING_GROUP" ; then echo "Group with GID exists ($EXISTING_GROUP=$NEW_GID)."; else echo "Updating UID:GID from $OLD_UID:$OLD_GID to $NEW_UID:$NEW_GID."; sed -i -e "s/\(${REMOTE_USER}:^:*:\)^:*:^:*/\1${NEW_UID}:${NEW_GID}/" /etc/passwd; if "$OLD_GID" != "$NEW_GID" ; then sed -i -e "s/\(^:*:^:*:\)${OLD_GID}:/\1${NEW_GID}:/" /etc/group; fi; chown -R $NEW_UID:$NEW_GID $HOME_FOLDER; fi;
2023-09-21T01:54:00.743Z
2023-09-21T01:54:00.877Z ---> Running in 51a5cb1efb24
2023-09-21T01:54:01.271Z Updating UID:GID from 1000:1000 to 1000055:1000001.
2023-09-21T01:54:01.276Z chown: changing ownership of '/home/vscode/.bash_logout': Invalid argument
chown: changing ownership of '/home/vscode/.bashrc': Invalid argument
chown: changing ownership of '/home/vscode/.config': Invalid argument
chown: changing ownership of '/home/vscode/.zshrc': Invalid argument
chown: changing ownership of '/home/vscode/.profile': Invalid argument
Dev container gives invalid argument for chown · Issue #9268 · microsoft/vscode-remote-release · GitHub
userns-remap: Container failed to build during updating UID:GID · Issue #9007 · microsoft/vscode-remote-release · GitHub
なんか結局、スッキリした方法はなさそう。
クラスターでは"remoteUser": "root"にしよう。
arachnidaやっぱりテストちゃんとやろう
ghciデバッグができるようにしよう。
やっぱりテストに時間がかかるのは辛すぎる...
テスト時間が3s -> 5minになるだけで普通に週単位で時間溶ける
libtool: warning: remember to run 'libtool --finish /usr/local/lib'
は、libtool が共有ライブラリ（ここでは libssh2.so など）を /usr/local/lib にインストールした後に表示する定型メッセージです。
libtool --finish <dir> は、
1. 古い HP-UX など一部の UNIX 系 OS で、共有ライブラリの実行時検索パス (run-path) を後処理で書き換える
2. .la ファイルを書き直す
といった追加作業を行うためのコマンドです。
Linux では通常まったく不要で、実行しなくてもライブラリは問題なく使えます。パッケージングスクリプトなどがクロスプラットフォーム対応のために呼び出すことがありますが、呼ばなくても害はありません。
つまり「インストール済みのライブラリを使うなら気にしなくていい警告」だと覚えておけば OK です。
やっぱりNixOS VMをmacでどうしてもbuildしたい...
いつでもflake.nixから完全に隔離された環境を一発で手に入れられることは精神衛生に良い
「この環境がどうしても手に入らない」があり得なくなる
nix.linux-builder = enableでいけた...!
どこ読んでもなかった(nixはドキュメントがカスなのが有名)だが、nix-darwinのdeepwikiに聞いたら一発
deepwikiのnixとの相性良すぎ?というかdeepwikiによってnixの弱点であるドキュメンテーションが大幅に改善されつつある。
関数型言語はLLMとの相性が良い?
Running a NixOS VM on macOS - Tweag
これ見ていきなり自分のvmに適用しようとして #時間溶かした
carefullyに読んだら動いたし色々理解した
PoCをこまめに実行してから進める
横着しないこれ大事
AIに丸投げとかダメ
VSCodeで^-は前いたところに戻る
Nixにしたことによって、clangのコンパイラー フラグとか全部明示的に書かないといけなくなって、最初は面倒くさかったけど、ClangD がめっちゃよく動くし、やっぱり全てを明示的にした方がいいなと思った。
clangdを使う以上はcの開発環境をLLVMファミリーに揃えてみた。
gcc -> clang
これ+bear -- makeでLSPとコンパイラーの挙動が完全に揃うので、非常に気持ちがいい。
gdb -> lldb
macだと標準だが、linuxでも入る
まだ試してないけど、クラングでコンパイルしたやつだと、やっぱり LLDB の方がいいみたい。
p foo->bar等エクスプレッションがうまく機能する。
cluster2nix.sh + NixOS VMが大活躍